home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / tsql / doc / glossary.mail / 000006_info-tsql-sender_Fri Oct 30 16:26:19 1992.msg < prev    next >
Internet Message Format  |  1993-06-11  |  3KB

  1. Date: 31 Oct 1992 09:36:46 +0930
  2. From: roddick@unisa.edu.au (John Roddick)
  3. Subject: Re: Temporal-database concepts and terms
  4. Sender: majfr@adder.levels.unisa.edu.au
  5. To: tsql@cs.arizona.edu
  6. X-Envelope-To: tsql@cs.arizona.edu
  7. Content-Transfer-Encoding: 7BIT
  8. Content-Length: 2577
  9. Status: RO
  10. X-Lines: 63
  11.  
  12. The following two entries are prompted by an apparent confusion in the
  13. literature regarding the two terms Schema Evolution and Schema Versioning. 
  14. In many papers they are used interchangeably which I believe is wrong as
  15. the definitions demonstrate.
  16.  
  17. \subsection{Schema Evolution}
  18.  
  19. \entry{Definition}         
  20. A database supporting schema evolution permits the modification of the
  21. database schema without loss of extant data.
  22.  
  23. \entry{Alternative Names}   
  24. Schema Versioning is a separate but allied concept which allow user
  25. definition of schema changes - see definition.  
  26.  
  27. Some thought was also given to using the terms 'data evolution' and 'schema
  28. evolution' but these were rejected due to the latter's usage in the
  29. literature.
  30.  
  31. \entry{Discussion}
  32. i.   In it's simplest sense, schema evolution does not imply full
  33. historical support for the schema; only the ability to change the schema
  34. definition without loss of data.  In practice, retention of past
  35. definitions will probably be appropriate.  In contrast, Schema Versioning,
  36. even in its simplest form, requires that a history of changes be maintained
  37. to enable the retention of past schema definitions.
  38.  
  39. ii.  The significant difference between evolution and versioning is the
  40. ability for users to identify quiet points in the definition and 'label'
  41. the definition in force at that time for later reference.  Schema Evolution
  42. does not require the ability to version data except in so far as each
  43. changed schema can be considered a new version.
  44.  
  45. iii. Schema changes will not necessarily result in a new version. 
  46. Typically schema changes will be of a finer grain than the definable
  47. versions.
  48.  
  49. iv.  Versions will tend to be labelled by some user-defined method whereas
  50. schema evolution changes are referred to more often by the (transaction)
  51. time of change.
  52.  
  53.  
  54.  
  55. \subsection{Schema Versioning}
  56.  
  57. \entry{Definition}         
  58. Schema Versioning is accommodated when a database system allows the viewing
  59. of all data, both retrospectively and prospectively, through user definable
  60. version interfaces.
  61.  
  62. \entry{Alternative Names}   
  63. Schema Evolution is an allied concept.
  64.  
  65. \entry{Discussion}
  66. See discussion under Schema Evolution
  67. John.
  68. -------------------------------------------+--------------------------
  69. John Roddick                               | Ph.  (08) 302 3643
  70. School of Computer and Information Science | Int. +61 8 302 3463
  71. University of South Australia              | Fax  (08) 302 3381
  72. The Levels                                 | Int. +61 8 302 3381
  73. SOUTH AUSTRALIA     5095                   | Net. roddick@unisa.edu.au
  74.